-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run nightly build only if repository has changes #112
Run nightly build only if repository has changes #112
Conversation
Btw. you can use https://nektosact.com/ to run GitHub actions locally 💪 |
With this two rounds you would see, how it works in action
With this solution, you will only build your images nightly, if there were commit changes. So it doesn't matter, if the latest commit is 24 hours ago or not, as if you want to build if there are any changes. |
As I interpret your changes, the nightly now runs automatically in every fork of the main repo. That this is desired should only very rarely be the case. On the one hand, not everyone who creates a fork of the repo also has an account on Docker Hub, so that an error occurs when pushing. Secondly, it is not in the interests of users to flood Docker Hub with a large number of Apus images with different users. Your other customization of checking when the last build ran, on the other hand, I think is very good. |
Thanks for your answer. We could also only run the build job, if the user configured a DOCKERHUB_TOKEN in the secrets. So this should not be a problem, and would be configurable and not hard-coded in the file. Probably we could also configure, on which branches this workflow should run or under which conditions. |
Furthermore, as GitHub writes here https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow the scheduled workflow are disabled on forks. The user must activate it by themselves. So if the user does choose that, I think it's okay that these are triggered then. |
I would prefer to add a condition to run only when |
1e7b4d4
to
36308d7
Compare
36308d7
to
7def7b4
Compare
I've now refactored the solution and tried it on my personal branch:
Check out the changes and thanks for your feedback! |
This is a rework from the solution #110, and it's better.
It solves a lot of problems which can occur based on the Git commits, see this comment on Stack Overflow https://stackoverflow.com/a/76596449/7262345
Furthermore, I've removed your hard-coded username, as I want also be able to run the workflow on the fork. I've tried it out and I was able to build and push to DockerHub and also verify, that these changes should work.
Try it out! 🚀 I'm happy to hear your feedback.
Furthermore, it's enough to add a secret for the
secrets.DOCKERHUB_TOKEN
. If the GitHub and Docker username is the same, we don't need to define it as a secret.If you want to have it dynamically, why you then hard-code the tag and repository? In case we need that, I would suggest making the whole thing dynamically and add multiple environment variables in a new PR, so that tags, repository, username, repository owner check.